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Executive Summary 


A comprehensive review of the literature and historical background of 
NASA established a need for an easy-to-implement technological improvement 
to displaying procedures which is cost effective and risk reducing. Previous 
unsuccessful attempts have led this team to explore the practicality of using a 
mobile handheld device. The major products, inputs, resources, constraints, 
planning and effort required for consideration of this type of solution were 
outlined. After analyzing the physical, environmental, life-cycle, functional, and 
socio-technical requirements, a Functional Analysis was performed to describe 
the top-level, second-level, and third-level functions of the system requirements. 
In addition, the risk/value proposition of conversion to a new technology was 
considered and gave a blueprint for transitioning along with the tasks necessary 
to implement the device into the Vehicle Assembly Building's (VAB) current 
infrastructure. A Work Breakdown Structure (WBS) described the elemental 
work items of the implementation. 

Once the viability of this system was confirmed, a device was selected 
through use of technical design comparison methods including the Pugh Matrix 
and House of Quality. Comparison and evaluation of the Apple iPhone, 
Motorola Q, Blackberry, PC Notebook, and PDA revealed that the iPhone is the 
most suitable device for this task. This paper outlines the device design/ 
architecture, as well as some of the required infrastructure. 
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I. Introduction 


A. Procedures at NASA 

National Aeronautics and Space Administration (NASA) approved 
procedures are written for the main assembly, maintenance, pre-launch ground 
check-out, and inspection tasks that are currently performed in the Vehicle 
Assembly Building (VAB) during Space shuttle build-up and storage operations 
(KSC, 2007). These procedures contain steps and instructions for very involved 
tasks performed by highly trained technicians. For example, a typical check-out 
procedure includes long hydraulic operations, powering up different parts of 
avionics, pressurizing and depressurizing the orbiter, and other work lasting up 
to 24 consecutive hours (Semmel et al., 2006). 

Design engineers create and document the initial procedures for assembly, 
integration, and maintenance work for ground operations for each launch 
vehicle. The creation of these procedures results in large manuals consisting of 
printouts in three-ring binders. The procedure information is disseminated to the 
technicians through paper-based procedure manuals. When a technician is 
completing a procedure and encounters an error either in the procedure or the 
assembly, the technician completes an error reporting form and submits the 
form. The information is either entered into the Problem Reporting and 
Corrective Action (PRACA) system or submitted as a Procedure Change 
Request. The design engineers receive notification of the procedure error and 
make corrections to the procedure manual. Figure 1 illustrates the current system 
within the NASA design environment. 
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Figure 1: Current NASA design environment 


NASA has been a government agency since 1958 (NASA, 2007c). NASA 
programs are funded by Congressional budget which require various procedures 
to have signoff levels. NASA uses a tremendous amount of procedures in all of 
its activities and each requires various signoff levels. The signoff methodology in 
addition to being politically motivated is also a risk management technique. The 
current NASA design environment suffers from several issues regarding the 
problem reporting process and distribution of updated procedure information. 
The paper-based processes increases the risk of lost forms, time delay in the 
transfer of forms, as well as restrictions on length of error explanations due to 
form size. Other issues concern the extensive process of updating the paper 
manuals with corrected procedure information. In order to ensure the 
technicians are made aware of the procedure change, the previous manuals must 
be located and the incorrect procedure steps must be replaced. 

During the transitions from the Space Shuttle Program to the 
Constellation Program, the environment will be more susceptible to procedural 
errors. Most of the Constellation Program is based on systems originally 
developed for the Space Shuttle Program, although structured vehicle design is 
more closely related to the Apollo Program. This evolution requires the 
management of production transition to align the specific, better-known (but still 
evolving) domain of the Space Shuttle Program to the greater complexity and ill- 
defined parameters of the Constellation Program. While the assembly, 
integration, and maintenance procedures of the current Space Shuttle Program 
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are established and explicitly defined, the knowledge base and operational 
processes for the Constellation Program vehicle are being generated while the 
vehicle is being designed. 

Operational knowledge from the Apollo Program has been lost due to 
workforce retirement and lack of documentation management. In the spaceflight 
domain, operational knowledge is defined as the documented and implicit 
information used to produce an appropriate outcome, such as a successful 
mission. These workforce and documentation issues affect the Constellation 
Program because the Apollo Program configurations were applicable to the 
required operational knowledge. The workflow procedure and operational 
knowledge gap between the Space Shuttle Program and the Constellation 
Program must be bridged. 

NASA has been interested in developing and utilizing technological 
solutions to bridge the various disconnects. Electronic filing procedures and 
organization wide databases such as PRACA have been implemented in a 
genuine attempt to improve operations. However the attempts have not been 
completely successful. Some possible reasons for the failures are due to the fact 
that most solutions have been engineer centric and not technician centric. The 
unsuccessful implementation of previous solutions has not improved the quality 
of intra-organizational communication, measured by paperwork. Also the efforts 
seem almost an afterthought rather than being targeted at pro-active 
management of obsolescence. 

Procedural changes can face difficulties due to conflicting perceptions of 
decision makers. Some believe that evolutionary changes can only be made to the 
designs or hardware/ software components and that the only way to perform a 
procedure is through the engineer-developed way. These incorrect beliefs should 
not propagate to new procedures, since this would serve to lengthen correction 
times and may result in imperfect or unsafe solutions. The optimum procedural 
system would develop and store knowledge about successful procedures, 
monitor success rates, and record incidental information which could help in 
retracing steps and rectifying procedures. 

B. Problem Background 

The Crew Exploration Vehicle (CEV) will be America's spacecraft for 
human space exploration after the Space Shuttles retire from active service. The 
Constellation Program proposal calls for the CEV to be operational by 2014, 
reflecting the President's and NASA's vision statements. The CEV is not 
intended to be a replacement for all types of space launches. Preliminary studies 
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by NASA have indicated that each spacecraft can be flown up to 10 flights and 
may be all or partially reusable (NASA, 2007a). Figure 2 shows the number of 
successful space shuttle launches through January 2007. Based on current 
knowledge of NASA's vision for CEV, it can be safely assumed that CEVs will 
also follow the low production volume (LPV) model. 



Year 


Figure 2: Number of Space Shuttle launches per year until 01/2007 (NASA, 2007a) 


This project will require a narrowed focus on a particular location at 
NASA ground operations to make the prototype discussion more straight- 
forward. After reviewing ground operations at Kennedy Space Center (KSC), 
the VAB was chosen for the scope of this project. NASA will retire the space 
shuttle in 2010, and in 2008 the VAB will start the transition for the assembly and 
processing of the CEV which makes it ideal for this project (International 
Information Programs, 2005). NASA is an enormous entity, but focusing on the 
operations, facilities, and parts within the infrastructure of the VAB will mitigate 
the range of risks. For the purposes of this project, the focus will be on 
communication between Shuttle and Ares and the existing experience base 
located at the VAB. 

The LPV model is suitable for the CEV for two reasons. There is a small 
demand for CEVs; therefore NASA can more thoroughly implement the 
numerous safety standards and restrictions. The low production can more easily 
handle potential changes in the design, production, and assembly processes. 
Unfortunately, the LPV environment brings along its own set of problems: the 
learning curve increases since technicians have only a few opportunities to learn 
a skill. In the case of the CEV, the problems of LPV get further compounded by 
the fact that CEV blueprints are comprised of design modifications and 
improvements to the Apollo and Space Shuttle. None of the employees from the 
Apollo era will be available to NASA during CEV operations, and countless 
current employees are reaching retirement age in this decade, thus, contributing 
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to the knowledge and expertise disconnect. The following statement illustrates 
the financial impact: 

"Way back in the 1960s [NASA] spent $24 billion (in 1969 dollars)— and at one 
point employed 400,000 people— to send 12 astronauts to the moon. But in the 23 years 
since the Apollo program ended, the engineers who carried crucial know-how in their 
heads, without ever passing it on to colleagues, have retired or died (or both). At the same 
time, important blueprints were catalogued incorrectly or not at all, and the people who 
drew them are no longer around to draw them again. So to fulfill the Bush 
administration's promise to return to the moon in the next decade, NASA is essentially 
starting all over again. Estimated cost to taxpayers in current dollars: $100 billion." 
(Fisher, 2005) 

NASA has experienced setbacks due to lack of funding and technology 
issues. In an attempt to increase efficiency, safety and reduce ground operations 
costs, it has pushed for improvements in integrated display interfaces (Pell & 
Shafto, 2004). Ground operations technicians and maintenance personnel would 
benefit from the use of handheld devices that would promote contextually 
effective interactions. NASA has considered various options and technological 
solutions to improve interfaces used by the crew and technicians. Members of the 
Real-Time Software Engineering Branch at the Goddard Space Flight Center have 
developed and evaluated usage of wearable, wireless, voice-activated computers 
using many off-the-shelf components (Pfarr et al., 2001). Similar studies have 
been performed to investigate usage of wearable, voice activated computers in 
restrictive environments such as clean rooms (Graves & Lupisella, 2004) and on 
task performance using wearable devices in crew maintenance activities by the 
Habitability Division at the Johnson Space Center (JSC). 

There will be a new learning curve for the CEV program, where 
knowledge will be gained through both successful and unsuccessful completion 
of procedures. The knowledge and expertise disconnect from past to present 
NASA programs will be a challenge to contend with, in NASA's future 
operations such as lunar assembly structures and long duration space missions. 
The significance of knowledge transfer heightens with the growing need to 
reduce problem resolution errors and time. The purpose of this project is to 
develop and examine a systems based solution to improving the communication, 
safety, and efficiency for ground operations processes and procedures at NASA. 
This systems engineering approach will facilitate space exploration technology 
and the factors directly affecting mission execution and success; thus, fulfilling 
the President's and NASA's agendas. Specifically, this project will explore 
whether operations can be improved when assisted with a portable electronic 
device as well as the obstacles to, requirements of, and infrastructure for 
transitioning to such a device. The remainder of this paper will clearly outline 
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the systems processes and methodology for using a portable, web-enabled device 
to complete operational procedures at NASA. 


II. Systems Engineering Process 

A. Systems Engineering Process Planning 

A new system utilizing both commercially available products and existing 
NASA technology has been envisioned to help NASA reduce ground processing 
person-hours, increase efficiency, improve safety, and reduce ground operations 
costs at KSC. Technology evolutions in mobile devices will be incorporated in the 
work-flow to help achieve the goal with low implementation cost and high 
results. 

Major products and results from process 

There are two levels of system - technological and infrastructural. The 
technological level would encompass the databases and the mobile device. A 
procedure database was created for the Delta and Atlas launches, which have 
benefited from the electronic procedure/ work control systems. The technology 
already exists in NASA, it needs to be expanded and implemented in other areas. 
Electronic procedures would be highly interactive and dynamic. Parts of the 
procedures can be updated whenever new procedural steps are included or 
deleted. The PRACA database exists in NASA but its implementation was not 
fully integrated with other aspects of production planning and control. 
Technology in the field of mobile devices is advancing at a very fast pace and 
many tasks which required the technicians to leave their workplace can be now 
performed without doing so. For the implementation of the proposed system, the 
technicians should be able to access the databases using the internet or intranet. 
This in turn means that the databases should be on a NASA server and all the 
technicians should have the right to access internet. This requirement raises 
infrastructural issues. This is the other level of the system. Infrastructural 
changes need to be made to accommodate the requirements of the proposed 
system. 

Process Inputs 

Infrastructural changes are also important to the introduction of the 
proposed system. The mobile device would require communication capabilities 
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at the technicians' workplace. A communication tower for good reception is 
required. The mobile device needs to have both short and long range wireless 
capabilities to access the procedures and report errors using the internet/intranet. 
These technologies might interfere with the working of certain components of 
the assembly. It might seem expensive to make the infrastructural changes for 
VAB only. But in the long run if the cost of implementing the infrastructural 
changes in all the NASA facilities is considered, the reduction in production cost 
would be much higher than the implementation cost. 

The proposed system would work with the integration of a procedure 
database (where the procedures for the assembly tasks would be stored) and the 
PRACA database (used for error reporting and prevention) which would be 
accessed using a mobile device. 

Constraints 

Implementations of the infrastructural changes pose numerous constraints 
to the implementation of the proposed system. Changes in the infrastructure 
without compromising document security are a major issue. NASA procedures 
are sensitive and security is a high priority. The databases should be on a NASA 
server and all the technicians should have the right to access internet. Highly 
secure password protected networks should be used to prevent unauthorized 
access to the wireless network. The mobile devices used can also be password 
protected to reduce the risk of proprietary information being leaked, and all 
emails and internet usage crossing the wireless network should be completely 
encrypted. 

Resource Allocation 

Resources for the proposed system are the mobile devices which should 
be available to quality, safety, and engineering personnel, specifically technicians 
and inspectors, working at VAB and the two databases (procedure database and 
PRACA) which should be accessible to all. 

Work Authorization 

The present system at NASA is an authoritative system. All the 
technicians have a supervisor to whom they report. Whenever an error is 
detected, it is reported to their supervisor who passes the information on to the 
engineering group. With the proposed system, the time to report an error would 
be considerably reduced. The problem reporting to the supervisor can be done 
using the mobile device without leaving the worksite. Also the technicians 
would have the freedom to report errors directly in to the PRACA system. 
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Allowing the technicians more involvement in editing the procedures will help 
create better, more technician-centric, procedures. 

Verification Planning 

The error reporting and error correction will be done electronically to 
verify the status of the error. Also, as the procedures would be accessed online 
from the procedure database, it would be easier to detect where the error 
occurred, whether the procedure is wrong or the technician made a mistake. The 
proposed system would considerably reduce the error detecting and recovery 
time. 

Subcontract/supplier technical effort 

The PRACA database is already being used by NASA in a limited 
capacity, but the proposed system will rely on it extensively. The mobile device 
is a commercially available off-the-shelf product. In-house production is a good 
option for security reasons. If it is subcontracted the risk of security will be high. 


B. Functional Analysis and Allocation 

A functional description of the system is necessary during the preliminary 
identification of resources required for a system to complete its purpose 
(Blanchard & Fabrycky, 2006). The functional flow block diagram in Figure 3 
depicts the top-level, second-level, and third-level functions of the system 
requirements. 
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Figure 3: Functional Flow Block Diagram (after Fabrycky & Mize, 2006) 


At the top-level are the high-level administrative requirements. Back in 
January of 2004, President Bush publicly announced a new vision for space 
exploration and returning to the moon. NASA then announced new goals for the 
next two decades requiring the CEV to be ready in 2014. Shortly thereafter a 
request for proposals was released and Northrop Grumman, Boeing, and 
Lockheed Martin submitted bids to do the build the vehicle. At the same time, 
there was ongoing improvement to mobile computing technologies with small 
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screen sizes. Once the contract was awarded to Lockheed Martin, the NASA 
centers began their preparations. 

Currently at the second-level phase, management is developing 
requirements for personnel, resources, and equipment. Ground operations 
funding for system improvement techniques are in the process of being 
approved and detailed requirements from the VAB business units are being 
developed. Next, several design alternatives and types of handheld devices will 
be evaluated. Finally, the human factors and production requirements will be 
established and a full release version of the iPhone will be obtained for testing in 
a high fidelity environment. 

The functions at the third-level are directly involved with production. 
Once the VAB is found to be compliant to the device architecture requirements, 
the technicians will receive training; materials and equipment that support the 
device are acquired; and new procedures are uploaded to the server. Once the 
selected device is placed into regular use, system maintenance and 
documentation of lessons learned are ongoing continual processes which provide 
feedback to the system. Appendix I documents the resources that must be 
allocated for each function described in the system requirements. 

C. Requirements Analysis/ Validation 

Constellation Program vehicles. Ares and Orion, require optimum ground 
operations to improve productivity, safety, and cost-effectiveness, which will 
enable these vehicles to launch on time. As shown in Figure 4, these efficient 
ground operations need to be implemented by early 2010. Technology must be 
selected for both the device and infrastructure. First, a multi-functional device for 
technicians is required to facilitate information transfer within the organization: 
engineers, managers, inspectors, other technicians, etc. This device will outline 
the requirements for the infrastructure. 
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Figure 4: Constellation Program Exploration Roadmap (NASA, 2007b) 


The requirements for this multi-functional device are based upon known 
operational and task requirements. 

Physical Requirements/ Human Factors 

■ Handheld: Technicians need to be able to take this device wherever 
procedures need to be performed; this implies both lightweight and 
portable. The device cannot be too large or heavy which could prevent 
technicians from accessing critical assembly areas. 

■ Wearable/ Stand Alone: Technicians need to be able to wear the device in 
situations where there is no appropriate area to place the device or when 
they need to access the device immediately. 

■ Easy to Learn: The device should not require extensive training. The device 
is a means to improve progress, not to interfere. The device needs to fit the 
technicians' knowledge and be user friendly. 

■ Multi-functional: The device needs to offer many features since the 
technician cannot carry and utilize multiple devices at one time. 
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Environment 

■ Limited interference: It is integral that the device not interfere with any 
portion of the assembly. Therefore, the device needs to be non-magnetic, 
non-corrosive or reactive with chemicals, and in compliance with part 15 
of the FCC rules. 

■ Backlit: Technicians may be required to work in low lit areas where they 
must be able to follow procedures and communicate with others. The 
device screen needs to be visible in situations where there is little or no 
lighting. 

■ Climate: The device must function within the VAB throughout the year 
with temperatures ranging from 19°F to 101°F (Weather Channel, 2007) 
and an annual humidity of 90% (CityRating, 2002). 

■ Range: The device needs to work throughout the 129,428,000 cubic feet 
(KSC, 2007) of the KSC VAB. 


Life-Cycle Issues 

■ Durable: The device needs to handle daily wear: resistant to scratches and 
dents and withstand being dropped from a short distance (< 2 ft). 

■ Cost: The device needs to have a low Risk/Value Proposition. This means 
that there needs to be a low risk and a high value. The device should 
contribute a large value to the project and have low associated risks. High 
value implies multi-functionality in that the device should have many 
features of several devices both reducing the cost of several devices and 
enhancing the capability of the one device. 

■ Low maintenance/ serviceability: The device needs to function with no 

interruptions to daily work. Any routine maintenance should not interfere 
with daily work. 

■ Reliability: The mean time to failure should be 12 hours usage for 300 days 
(3600 hours). 

Functional Performance 

■ Access/ contain electronic media: The device needs to be able to display 
electronic media such as PDFs, pictures, videos, audio clips, etc. which 
will allow the technicians to perform procedures. 

■ Access internet/ email: The device needs to allow technicians to 
communicate electronically with other members associated with the 
program. This will help increase communication and reduce time lag 
between individuals. 
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■ Phone: The device needs to allow technicians to call other members 
associated with the program. This will reduce the information lag between 
individuals since technicians would not have to wait for a response by 
email or leave their work place to speak with someone. 

■ Camera: Technicians need the ability to communicate visually with 
members associated with the program. The ability to take pictures can 
enhance the information transfer and allow for problem areas to be 
handled quickly and appropriately. 

■ Memory: The device needs to be able to store procedures, pictures, or 
notes. The device should meet current standards. 

■ Battery life: The device cannot stop working during a procedure and 
should last at least 4 hours. Battery life is determined as half of an 8 hour 
work day. It must be rechargeable within 4 hours. 

■ Adaptable: The device should allow for improvements and changes to be 
made during the life cycle. This is integral to assure optimum 
performance. 

■ Wireless: The device needs to be able to access information both short and 
long range. It should meet the current wireless standards. 

Social, Political, and Legal Requirements 

■ Safe: The device can not place any of the technicians in physical harm. 

Requirements for the infrastructure are approximated and given below. 

Environment 

■ Range: The system needs to enable the device to work throughout the 
129,428,000 cubic feet (KSC, 2007) of the KSC VAB. 

■ Communication: There needs to be a communication tower to support the 
device. 

Functional Performance 

■ Procedural Databases: The system needs to allow NASA personnel to 

access PRACA and procedures database. 

■ Access internet/intranet: The system needs to allow NASA personnel to 
access information through the internet and/or intranet. 

Social, Political, and Legal Requirements 

■ Legal : The electronic signature needs to be considered a legal signoff. 

■ Security: Allow only authorized users to access the system. 
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D. Systems Analysis and Control 


Systems analysis is the comparison of different alternatives, across 
multiple criteria, to help identify and make better decisions. The typical use of 
systems analysis is to guide decisions on issues such as national or corporate 
plans and programs, resource use and protection policies, research and 
development in technology, regional and urban development, educational 
systems, and other social services. Quality Function Deployment (QFD) is a 
flexible and comprehensive group decision making technique and is used for 
comparing various alternatives. The Pugh Matrix is a scoring matrix used for 
concept selection, in which options are assigned scores relative to criteria. The 
device selected from the Pugh Matrix and QFD analysis is then analyzed in 
detail. Interface management for the device is carried out to ensure interface 
definition and compliance of the system with other system elements with which 
it interoperates. A Work Breakdown Structure (WBS) captures all the elemental 
work items of a full-scale implementation in an organized way. A Gantt chart is a 
matrix cross listing work items and estimated task duration. In risk-benefit 
analysis, a value is assigned to a sample set of existing risks so as to make 
possible a comparison of the discounted sum of these costs. The risks considered 
are usually events whose probability of occurrence is low, but whose adverse 
consequences would be important (e.g., events such as an explosion of a 
component on CEV or failure to launch on time). The system can be broadly 
classified as shown in Table 1. 


Table 1: Systems Classification 


Category 

Value 

Risk Class 

Technology demo (more technology 
oriented than theory -based) 

Development schedule 

Fast (< 2.5 years) 

Lead organization (KSC) level of 

Medium. There is a level of expertise 

expertise 

available with respect to implementing 
electronic procedures in the form of 
PRACA 

Software Heritage 

Medium. PRACA has been implemented 
in desktops and can be reused to some 
extent 

Software Architecture 

Java, OS X 

Design Complexity 

Medium. New routing and access 
structures would need to be developed 

Hardware Heritage and 

No heritage, since iPhone or any similar 


14 



Redundancy 

component has not been in use. There 
would some redundancy as it is aimed at 
replacing paper and desktop PRACA 


versions 

Training required 

Technicians will need to be trained on 
using the iPhone capabilities and using 
the correct procedures 

Instrument Support 

Low with routine maintenance. Possibly 
some interaction with other instruments 


in the future. 


Based on the above classification, advanced products viz. PC Notebook, 
PDA, Blackberry, Motorola Q and iPhone were selected as candidate devices. 
These devices were then subjected to different analysis based on the 
requirements stated in the previous section, to determine the best fit for the VAB 
environment. 

Quality Function Deployment 

QFD is a flexible and comprehensive group decision making technique used 
in product or service development, brand marketing and product management. 
QFD can strongly help an organization focus on the critical characteristics of 
products or services (new or existing) from the viewpoints of the customer 
market segments, company, or technology-development needs. QFD uses a 
series of matrices to represent the product comparisons and is sometimes 
referred to as the House of Quality (HOQ) due to its distinctive house shaped 
appearance. The QFD methodology is based on a systems engineering approach 
consisting of the following general steps: 

1. Derive top-level product requirements or technical 
characteristics from customer needs. Once needs are 
summarized, consider whether to get further customer feedback 
on priorities. Undertake meetings, surveys, focus groups, etc. to 
get customer priorities. State customer priorities using a 1 to 5 
rating, with 1 indicating not important to 5 indicating most 
important. 

2. Develop product concepts to satisfy these requirements. 
Correlate the customer needs with the concept features. These 
help define the degree to which as product requirement or 
technical characteristic satisfies the customer need. The weights 
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used are 1-3-9, with 1 indicating low correlation to 9 indicating 
high correlation. 

3. Determine potential positive and negative interactions between 
product requirements or technical characteristics using symbols 
for strong or moderate, positive or negative relationships. 

4. Calculate importance ratings. Multiply the customer priority 
rating by the improvement factor and the weighting factor 
associated with the relationship in each box of the matrix and 
then add the resulting products in each column. 

5. Evaluate product concepts using the 1 to 5 scale, with 1 
indicating worst and 5 as best, to select most optimum. The 
scale reflects how well an attribute was obtained and not in 
regards to its superiority to the other technologies. 

The HOQ, in Appendix J, determined the optimum device to be the Apple 
iPhone. Apple iPhone scored higher than other candidate devices with a total 
score of 297, indicating the best match between the product concepts and the 
developed requirements. The next best candidates were the Blackberry, PDA and 
MotorolaQ respectively. The paper version and the PC Notebook were found to 
be the least favorable candidates, indicating that an upgrade in technology to the 
tools might be helpful. The iPhone performed better on meeting the functional 
performance and physical requirements, as it combines much needed 
technologies in a user friendly environment and cost effective manner. 


Pugh matrix 

A Pugh Matrix compares concepts based upon the design/system 
requirements to determine the optimum device (Murugappan & Keeni, 2002). 
For the first iteration, one of the concepts is chosen as the datum. To this concept, 
all others are compared. Concepts which are superior are noted with a '+', 
inferior with a and similar with an 's'. After the concepts have been compared 
for all requirements, each concept's score types (+, - , s) are summed. The '-' sum 
is subtracted from the '+' scores to obtain the final value ('s' values do not 
contribute to the final score). Negative final scores imply that concepts are 
inferior to the datum and positive scores are superior. Iterations are performed 
with new datums until there is one remaining concept with a positive sum, 
implying that it is the best concept overall. 

The Pugh Matrix, Appendix H, determined Apple iPhone as the best 
device by comparing the physical characteristics, communication abilities. 
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display interface, and additional features of the Motorola Q, Blackberry, PC 
Notebook, and PDA. The Apple iPhone consistently scored higher. iPhone was 
the smallest device at 4.5" x 2.4" x 0.46". Its memory exceeded the others by far 
at 8000 MB and was one of the top two devices with the longest battery life. 
Among the devices that were both backlit and light sensing, it had the largest 
display size. 

Work Breakdown Structure and Gantt Chart 

WBS, Appendix C, is a result-oriented family tree that captures all the 
work of a project in an organized way. It is often portrayed graphically as a 
hierarchical tree or as a tabular list of "element" categories and tasks or the 
indented task list that also appear in the Gantt chart schedule (Appendix D). A 
Gantt chart is a matrix which lists on the vertical axis all the tasks to be 
performed. The horizontal axis is headed by columns indicating estimated task 
duration. For this document, each period is expressed in 3 months. It should be 
noted that the final implementation for this project should coincide with the 
Orion production and operations, as shown. This would enable better & longer 
workforce training leading to better Orion operations. Any slips in timelines and 
implementations would lead directly into the initial Orion productions and 
possibly leading to enhanced error rate. The ideal project approval time window 
would expire in the third quarter of 2007. 

Interface Management 

An interface is the formal and informal boundary/ relationship between 
people, organizations, and functions. Interface management is defined as the 
management of communication and coordination between the device and other 
components, both existing and future. A preliminary level analysis of first-level 
systems that the iPhone directly interacts with is shown in Table 2. The 
components of this analysis include: 

■ Interface Function: specifies "what" the interfacing system must perform 
(i.e., task, activity, or action). 

■ Design Interface Constraint: specifies codes and standards applicable to the 
interface, specific design, operating or maintenance configuration and 
essential features, etc. 

■ Physical and Performance Requirements : specifies physically related 
characteristics for components at the interface boundary as well as how a 
function must be performed. 
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Table 2: Interface Analysis 


System 

Interface 

Function 

Design Constraint 

Physical and 
Performance 
Requirements 

Technician Work 
Scheduler 

Inform technician 
of task / step at 
hand; Update 
central database 
upon completion 

I/P: Objectives from 
task; Procedure(s) and 
forms for task; 
Supporting 
information and 
timelines 
O/P: Time taken; 
Deviations as noted by 
the technician; Usage 
statistics & record for 
retracing time and 
steps 

Other: Scrollable: 
Trigger time and 
format can be selected 
by the technician 

Wi-Fi enabled; 
Support document 
formats (such as 
PDF); 

Touch screen 
enabled 

Voice 

Correspondence 

Allow for voice 
correspondence to 
and from the 
technician at any 
given time 

Should not interfere 
with technician 
performing an ongoing 
procedure step or 
filling out a form 

Wireless enabled 

Case / Issue 
Management 

Allow for filing of 
problem reports; 
Allow for filing of 
procedural 
compliance 
reports; Problem 
disposition status 
notification to 
technician 

Should allow for 
reporting and 
searching reports; 
Should allow for 
issuing updates; 
Should allow for 
electronic signoffs 

Wi-Fi enabled; 
Support document 
formats (such as 
PDF); 

Touch screen 
enabled 

Procedure 

Requirements 

Management 

Allow for filing of 
procedure 
problem reports; 
Problem 

disposition status 
notification to 

Report compliance of 
correct procedure; 
Report incompliance of 
correct procedure; 
Report compliance of 
incorrect procedure; 

Wi-Fi enabled; 
Support document 
formats (such as 
PDF); 

Touch screen 
enabled 
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technician; 

Support 

procedure 

rollbacks 

Report incompliance of 
incorrect procedure; 
Use Voice reports to 
supplement reports 


Procurement, 
Purchasing and 
Requisition 

Enable real time 
monitoring of 
product 
availablity and 
location 

Report component's 
usage and failure 
statistics; Report 
additional information 
on usage and failures 

Wi-Fi enabled; 
Radio Frequency 
Identification 
(RFID) detection 
enabled 

Content Authoring 
and Publishing 

Support 
procedure 
rollbacks; Support 
content change 
requests 

Notify wrong 
document retirements; 
Help update wrong 
content authoring 

Wi-Fi enabled; 
Touch screen 
enabled 

Support document 
formats (such as 
PDF) 


Risk Benefit Analysis 

The Risk Benefit Analysis is an evaluation of the current 
products/processes against the recommendations suggested in this report such as 
the iPhone and other electronic databases. These recommendations should result 
in a reduction of risks, in turn stemming financial losses and schedule creeps. 
The risks considered are categorized into technical risks, cost risks, schedule risks 
and program risks; and comprise primarily of risks relative to the currently 
preferred paper-based process. Technical risks comprise of failures of the 
product capabilities/process to achieve their desired intent. Technical risk exists 
if, in the system design and development process, it appears that the system will 
not meet a specific performance objective. The level of detail for these risks can 
vary. Detailed task level malfunctions are beyond the scope of this document. 
The risks in which the possibility of allocated budget will be exceeded are 
categorized as cost risks. Schedule risk can be incurred if the program schedule is 
not met or there is a task creep. Failure risks which can be attributed to 
occurrence of externally influenced events which impact this project technically, 
cost wise and schedule wise are categorized under programmatic risks. The 
scope and impact of all risks are listed vertically and correlated to each risk on a 
scale of High-Medium-Low. An estimate of the relative reduction in probability 
of each risk occurring, using the new product/process recommendation, on a 
scale of Small-Medium-High is done. The Risk Benefit Analysis, Appendix G, 
determined that recommendations showed a reduction in probability of 
occurrence these risks. The benefits due to the risk reduction can be easily 
estimated to exceed the cost of implementation of the new products. 
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E. Synthesis 

NASA ground operations presently use paper procedures to perform the 
tasks involved in building the Space Shuttles. A cost effective method is required 
to help technicians complete procedures and communicate with co-workers 
more efficiently and effectively. With the development of increasingly small, 
light, and mobile electronic devices, there is a need to understand how this 
technology can help technicians in their work. A Pugh Matrix was created to 
compare mobile technologies based upon the design/system requirements and 
determine the optimum device. From the results of the Pugh Matrix (Appendix 
H) and House of Quality (Appendix J) it was concluded that the Apple iPhone 
was the best mobile device that met our defined requirements. 

The basic requirements for a hand held device for NASA technicians and 
the features of iPhone that comply with these requirements is shown in the Table 
3. 


Table 3: Mapping of user requirements and features of iPhone (Frakes & Seff, 2007) 


Requirements 

Features of iPHONE 

Physical Requirements/ Human Factors 

Handheld 

Apple iPhone is 4.5in X 2.4in X 0.46in in 
size and weighs 4.8 ounces. 


A wearable cover can be designed for the 

Wearable 

iPhone which can be worn on the forearm 
or velcroed to the suit. 


The iPhone is easy to use as its works 
similar to an iPod (touch-sensitive) and it 

Steep learning curve 

has all the functions of a phone. The 
operating system is OS X, web browser is 
Safari and for convenience in typing it has 
a touch-sensitive QWERTY keyboard. 

Environment 

Limited interference 

iPhone does not interfere with magnetic 
fields. 

Backlit 

iPhone screen adjusts to the light of the 
area where it is being used. 

Environment 

iPhone can be used at normal temperature 
and humidity. 

Life-Cycle Issues 

Durable 

The touch screen is more resistant to 
scratches than the screens of iPod. 

Cost 

The iPhone costs $599 a unit. 
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Does not require any regular maintenance. 

Low maintenance/serviceability 

Any non-functioning parts (if there is any 
damage or repair) need to be sent to Apple 
for replacement or repair. 

Guaranteed function for certain time 

Apple's guarantee and warranty policy 


Since the first release of iPhone is in June 

Reliability (mean time to failure) 

2007, the reliability of the iPhone cannot be 
determined. 

Functional Performance 


iPhone comes with two storage capacities 
- 4GB or 8 GB. PDF documents can be 
opened in iPhone. Music and videos can be 

Access/contain electronic media 

watched from iTunes. If needed there is a 

(PDF, pictures, videos, audio) 

DVD ripper to convert audio/video 
formats to the Apple mp4 format. Pictures 
can be synced from a PC or Mac to send 
and view on iPhone. 

Access internet, email 

802.11b and 802.1 lg Wi-Fi. 

Phone capabilities 

Touch screen dialing. Conference calls. 
Interactive voice mail 

Battery life 

The Battery life is 5 hours talk- 
time/video/browsing, 16 hours audio. 

Ability to take pictures 

2.0 Megapixel camera 

Adaptable 

Apple allows different software to be built 

(allow for improvements, changes) 

and run on the iPhone. 

Social, Political, and Legal Requirements 

Safe (no danger of physical harm) 

All software built for the iPhone need to be 
approved by iPhone. 


Since the procedures used to create the CEVs will be different than those 
used to build previous vehicles, a good error prevention and reporting system is 
required. This system is needed to track down the errors, to prevent propagation 
of errors, and to rectify the errors as soon as possible. Apple iPhone can be used 
effectively in this process. The mobile device would be helpful accessing the 
procedure database to download online procedures, as well as report and correct 
errors using the online forms. The flowchart in Figure 5 shows the steps involved 
in following the procedure using the PRACA database and reporting errors if the 
procedure is wrong. If the technician feels that the procedure is wrong, he can 
either call his supervisor (assuming that a supervisor is responsible for a group 
of technicians) or check if he is using the correct procedure by searching the 
PRACA database to verify if he has the correct procedure. If he finds an error in 
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the procedure, he files an Interim Problem Report, Problem Report or 
Discrepancy Report online from his workplace using the Apple iPhone. 

In the present system, the technician uses paper procedure to do the 
assembly. If he finds an error in the procedure, he can either fill an online form 
on a computer at the Test and Inspection Records (TAIR) station or he can fill a 
paper form. Technicians do not carry these forms with them so they jot down the 
required information and fill the forms at the TAIR station either online or using 
paper forms. If they forget to write down some information, they need to go back 
to their workplace, write down the information and come back to the TAIR 
station to finish the form. Using the iPhone this process of moving back and forth 
for missed information will be eliminated and the error will be reported quickly 
(Linde & Wales, 2001). 


Case 1: The procedure is correct and the technician performs the 
task correctly. The task is done without any errors. 

Case 2: The procedure is correct but the technician performs the 
task incorrectly. There is an error in performing the task. 

Case 3: The procedure is wrong but the technician follows the 
procedure correctly. Though the procedure has been 
followed correctly there is still an error because the 
procedure is wrong. 

Case 4: The procedure is wrong and the technician makes a 
mistake in following the procedure. The task has been 
performed incorrectly. 

There is a fifth case which leads to error when the procedure is right and the 
technician completes the task without errors but there is a flaw in the design. 
Under such circumstances, the assembly will not work and the mission is not 
accomplished. This case is out of the scope of this paper and will not be dealt 
with, however the procedural system may be able to help diagnosis design 
problems. 
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Technician 
searches for the 
procedures and 
downloads/ 
accesses it from 
the Procedure 
data base 



Calls the 
supervisor using 
the iPhone and 
verifies using the 
procedure number 
whether he has 
the latest version 
of the procedure. 


Verifies in the 
PRACA database 
using the 
procedure number 
if he has the latest 
version of the 
procedure 


yes 


Gets confirmation 
(either from the 
PRACA database 
or from the 
supervisor) that he 
is using the right 
procedure 


Task has been 
successfully 
completed 


4-Yes 


Case 1 

Technician performs 
the task correctly 
Procedure is right 



supervisor using 
the iPhone and 
verifies using the 

procedure number 

whether he is 
using the latest 
version of the 
procedure. 


Files an Interim 
Problem Report, or 
Problem report or 
Discrepancy Report 
against the 
procedure using the 
procedure number. 


Waits for the 
correct procedure 
to be uploaded 
and proceeds to 
perform another 
task 


Case 2 

Technician performs 
the task incorrectly 
Procedure is right 


Case 3 

Procedure is wrong 
Technician follows the 
procedure correctly 


Verifies in the 
PRACA database 
using the 
procedure number 
if he has the latest 
version of the 
procedure 



Task was 
performed wrong 


Case 4 

Procedure is wrong 
Technician performs the 
task incorrectly 


Figure 5: Task Analysis Flow chart showing errors committed while using the procedure 
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There should be a method/process to find and rectify the errors 
committed (as shown above in Figure 5) while completing the task. One method 
to find an error that has occurred is to have a down stream technician alert that 
an error occurred if he determines the unit was misassembled. The technician 
files an Interim Problem Report, Problem Report or Discrepancy Report online 
using the Apple iPhone, stating that an error occurred during the assembly of a 
particular component. PRACA assigns a ticket number to the report and send an 
email to the supervisor whose technician was responsible for performing the 
task. The supervisor would then check whether the technician followed the 
correct procedure or if the procedure was updated after the task was completed. 
If the procedure was updated after the task had been completed, the supervisor 
assigns another technician to rectify the assembly using the correct procedure. If 
the procedure was correct but the technician performed the assembly incorrectly, 
the supervisor would assign the task to the same technician again and ask him to 
correct his mistake. The supervisor updates the error reporting system and closes 
the ticket. 

If the procedure has not been updated and the technician performed the 
procedure correctly using the wrong procedure, the supervisor files an Interim 
Problem Report, Problem Report or Discrepancy Report online using the Apple 
iPhone. He would wait till the problem has been resolved. After the problem has 
been resolved, he assigns a technician to rectify the error using the updated 
procedure. He closes the ticket after the job has been completed by the 
technician. Apple iPhone would help in speeding up this process as the 
technician need not report the error to the his supervisor who would in turn 
report the error to the supervisor whose technician made the mistake. Using the 
iPhone would reduce the time to rectify errors. Also, if a technician feels that the 
procedure is wrong he can raise a ticket in the PRACA database and can state the 
error and the correction (if he knows it). The engineers (who also have access to 
the PRACA database) can verify and update the procedure. This process will 
save critical assembly time. If a launch is delayed due to setback in assembly and 
manufacturing, NASA's reputation would be tarnished and millions of dollars 
could be lost. The flowchart of this proposed error management system is shown 
in Figure 6. 

Sometimes the components used in the assembly fail to work or the 
assembly does not work because of a design flaw and the mission is called off. 
There is a great financial loss in such situations. Quality or safety inspectors 
constantly inspect the assembled parts to verify if the assembly was performed 
correctly and if the all the components of the assembly are working. If they 
detect any flaws in the assembly or in the components, it is reported in the 
PRACA by filing an Interim Problem Report, Problem Report or Discrepancy 
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Report. Apple iPhone can help speed up this reporting process and the error can 
be rectified as soon as possible. In case there is a design flaw, this situation is 
beyond the scope of this paper. 

The Apple iPhone is a commercial off-the-shelf product, slated to be 
released in June 2007. The introduction of iPhone into the workflow of 
technicians would not require any new developmental items, except to make the 
procedures available in electronic format. All the other activities required of the 
technicians can be performed using internet facilities such as email, web 
browsing, etc. The new technology can be implemented with non-developmental 
items and hence it would be cost effective for NASA. Any software written for 
the iPhone has to be approved by Apple but, if the procedures are in a database 
that can be accessed using the internet, NASA would not have to get approval 
from Apple. 


25 


Assumptions: 

1. A supervisor is responsible for a group of 10 technicians 

2. The supervisor has a record of the procedures used by the technicians working under him. 

3. If a technician/quality or safety inspector detects that the task was performed incorrectly by a technician, he can report the 
error using the PRACA database. 

4. A database for all the procedures exists. 

Case 1 Case 2 Case 3 Case 4 

Technician performs Technician performs Procedure is wrong Procedure is wrong 

the task correctly the task incorrectly Technician follows the Technician performs the 

Procedure is correct Procedure is correct procedure correctly *•** incorrect, y 



Figure 6: Flow chart of the error management system 
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III. Transitioning Critical Technologies 


Currently the KSC VAB relies on a paper-based procedure system. The 
transition to a completely electronic-based procedure system is perfectly timed 
with the development of vehicles Orion and Ares. Procedures required to build 
these new vehicles are largely different from procedures in the past due to the 
new designs and technology. Existing designs, such as the Solid Rocket Boosters 
(SRB), will be used for the new vehicles; however these procedures will need to 
be updated and reproduced. 

The critical component of the transition lies in the framework which will 
facilitate the transfer of the electronic-based procedures. NASA's intranet web- 
based system will be utilized. This will allow only NASA employees to access 
web pages of documents, specifically procedures. Technicians need to be able to 
access the network from any location within the VAB; there should be adequate 
wireless coverage to accommodate this need. 

It is recommended that the number of iPhone units purchased equate to 
60-65% of the head count of technicians. This percentage accounts for the two 
work shifts of technicians (50%) and unavailable units (10-15%) due to low 
battery or damage. This will allow for technicians to recharge units while having 
access to fully charged ones. In the situation where a unit fails, there will be extra 
units to take its place. This is vital because instrument downtown could impede 
vehicle assembly. 

The iPhone was selected as the device of use since it performed best 
overall in the House of Quality (Appendix J) and Pugh Matrix (Appendix H). In 
addition, the iPhone was superior to the other technologies due to its multi- 
functionality and corresponding high value added features. 

Table 4 illustrates some potential risks involved with the transition to the 
new technology due to the infrastructure requirements. 


Tabic 4: Potential Risks Due to Transition of Technologies 


Risks 

Risk Mitigation 

Wireless network goes down 

Create network terminals with docking 
stations on wired system. 

Intranet server goes down 

Computer with dock-connector port 
containing most recent version of all 
documents. 

Data corruption/loss 

Redundant copies of documents placed 
on designated network computer. 
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IV. Integration of Systems Engineering Effort 


The ground operations at KSC's VAB are a complex system due to the size 
and magnitude of its many functions and operations. Development of a complex 
system requires organization and integration of design disciplines. Teams 
performing design disciplines within the complex system may be working at 
different levels of detail each exploiting its own style, expertise, and models. The 
technical disciplines in support of the integration of the systems engineering 
effort are: requirements analysis and generation, procedure development, system 
architecture development, system performance analyses, modeling, integrated 
test and verification, troubleshooting and anomaly resolution (MEI Technologies, 
2007). It is imperative that NASA invest in infrastructure architecture to 
rationalize, standardize, and structure their infrastructure landscapes. 

■ Requirements analysis and generation: Each team must generate well- 
defined and well-understood requirements for using the iPhone in their 
area. Analyzing and identifying functional and conceptual requirements 
can be a challenge; however, introducing new requirements into existing 
systems later on can result in costly rework or incorrect procedures. 
Preparing a transparent and structured taxonomy will yield greater 
insight into the elements of the complex infrastructure. 

■ Procedure development: Each team should announce its intention to 
develop procedures for their function allowing input at the outset from 
other teams. They will then conduct a technical analysis of the iPhone to 
evaluate potential assembly and maintenance task impact. Finally, the 
team will release draft procedures and review them periodically to make 
updates. The teams will rely on mail, calendar services, and other 
collaboration applications. 

■ System architecture development: System architecture outlines the overall 
configuration of the system and is vital to designing and developing a 
system comprising numerous elements that function as a whole. Each of 
the teams must define how their hardware and software related activities 
will affect use of the iPhone. 

■ Systems performance analyses: Management highlights the system 
characteristics, system conditions, operational performance, and 
quantitative system performance. 
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■ Modeling: Simulation teams model each of the subsystems and then the 
system as a whole along with any deviations from the iPhone's expected 
or predicted performance. This will be used to reduce cost during testing 
and verification. Simulation software will be used. 

■ Integrated test and verification: Testing teams and technicians test the 
subsystems and then the system as a whole. Safety assessments are 
performed. Threre will be integrated analyses of the iPhone's test 
procedures and the data functions to insure interface and safety 
requirements are satisfied. 

■ Troubleshooting and anomaly resolution: This final step will involve 
identification of production and maintenance anomalies; the 
determination of their causes, and a description of the approaches taken 
for corrective action. The role of each technical discipline to ensure timely 
and accurate resolution of the anomalies should be discussed in a 
technical report from each team. There should be a design review prior to 
production. Apple should have a customer support representative 
dedicated to iPhone use in the VAB. 


V. Implementation Tasks 


The final stage of the systems engineering life cycle is implementation of 
the new system. Before the system is implemented and fully functional in the 
NASA workflow, technology required for the new system should be verified, it 
should be checked whether the new system supports all the processes it will be 
used in and a prototype of the new system needs to be developed and tested. The 
results of the tests and evaluations will enable the design engineers to rectify 
flaws in the system and build a better version of the system for final 
implementation. 

A. Technology verification 

The pending release for Apple's newest technology, the iPhone, is similar 
to its Apple predecessors such as the iPod. The iPhone runs on a version of OS X 
optimized for the iPhone's hardware but still a familiar version to OS X users. 
The iPhone has a 3.5 inch touch-sensitive display with a resolution of 320 x 480 
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pixels at 160 pixels per inch, and is more scratch-resistant than the iPod screen. 
The iPhone is available with either 4 GB or 8 GB. The iPhone has a 2 Megapixel 
camera, which is essential for technicians to take pictures for procedures or as a 
means of visual communication. Pictures would enhance the communication 
between technicians and engineers/supervisors to illustrate where problems 
exist. The iPhone is a quad-band GSM phone. It works in the U.S and other parts 
of the world as well while under contract with AT&T. For wireless connectivity, 
it has a built-in 802.1 lb/g Wi-Fi. The iPhone also includes Bluetooth 2.0+EDR 
capabilities. The email client provided in iPhone can be used to access email 
through iPhone, which supports rich HTML and online images - it resembles OS 
X's mail application. 

Apple also provides free Blackberry-style push IMAP email to all iPhone 
customers. The iPhone users automatically receive notification when a new email 
arrives. The iPhone has a number of standard PDA functionalities - storing and 
displaying contacts, phone numbers, appointments, notes, etc. The iPhone's 
ability to take notes is an added advantage for technicians as they can notate 
important information that may be integral to the procedures. The iPod-syncing 
interface, a 30-pin dock-connector port, allows for data from the computer to be 
synced into the iPhone. For web browsing, iPhone supports a fully featured 
version of Safari. For typing emails and entering data, iPhone has an on-screen 
touch sensitive keyboard. The iPhone does not give a tactile feedback but it 
features automatic text detection and text prediction; selected keys also enlarge 
on selection as a form of feedback to the user. Third party applications can be run 
on the iPhone; however they need to be approved by Apple before they can be 
(Frakes & Seff, 2007). 

B. Process Proofing 

The iPhone is an appropriate medium to view electronic procedures since 
it supports viewing documents, pictures, and videos. An enhanced version of the 
procedure could incorporate a pictorial description or video to enhance the 
explanation of the procedural step. Improving the understanding of procedures 
could increase performance of technicians. The procedures used to build Ares 
and Orion vehicles will be updated simultaneously as they are built. Any errors 
in the procedures detected by the technicians would be reported and updated in 
the PRACA database. Implementation of iPhone would allow technicians to 
contact their supervisors or engineers to clarify questions about the procedures 
without leaving their workplace. Any pictures taken during the assembly could 
be incorporated in the procedure to help later technicians with the task. 
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In addition to iPhone being used to view electronic procedures, it could 
also benefit PRACA which is proposed to be used during the building of Ares. 
The error prediction and recovery systems are shown in Figure 4 and Figure 5 
Technicians can use iPhone to view procedures while assembling and 
manufacturing parts, verify whether the procedures they are following are the 
latest versions, and report any errors in the procedure. All this can be done from 
their workplace electronically. If a technician detects an error while assembling a 
part, he can raise a ticket in the PRACA database by filing an Interim Problem 
Report, Problem Report or Discrepancy Report and report the error. The PRACA 
system would alert the supervisor so that he could trace through the procedure 
to identify where the error has occurred and rectify it. If the procedure is wrong, 
he would file an Interim Problem Report, Problem Report or Discrepancy Report 
and update the ticket to alert the design engineer to correct and update the 
procedure. Once the procedure has been updated, the ticket would be closed. 
This process would be a detection and prevention of cascading errors. The entire 
process is executed online, at their respective workplaces. 

C. Development test and evaluation 

Before the implementation of the iPhone, test and evaluation of the device 
needs to be performed. The iPhone as well as its case/holder (which can be either 
strapped to the hand or velcroed to the technician's suit), and electronic 
procedures are the major items that need to be tested. Visual and audio electronic 
formats of procedures can be supported by iPhone. Visual formats include 
written documents or videos. Audio formats include sound bites or video clips. 
A usability test should be conducted to verify that technicians are able to use the 
electronic procedure and report errors without compromising with performance 
on a test PRACA database. Scenarios in which technicians need to access 
electronic procedures, detect and report errors will also need to be tested. Any 
short-comings detected with the usability test need to be corrected before iPhone 
is implemented. Figure 7 and Figure 8 illustrate how the iPhone could be used by 
technicians. 
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Figure 7: NASA technician performing an assembly task 



Figure 8: NASA technician uses iPhone to resolve an error 


Figure 9 demonstrates a how iPhone can be used to report an error while 
attached (via Velcro) to a work suit. 



Figure 9: Prototype of an iPhone being used to report an error in the procedure. 
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Another possible method of wearing iPhone is with elastic straps as 
shown in Figure 10. This would allow technicians to wear the iPhone regardless 
if their suits had Velcro or not. The iPhone is in a convenient position to do 
overhead jobs and look at the procedures at the same time. 



Figure 10: Prototype of an iPhone strapped to the forearm 


Figure 11 depicts prototypes screens for different functions that can be 
performed using the iPhone. Figure 11(a) shows the screen where the user has 
updated the PRACA database by closing a ticket. Figure 11(b) is a screen-shot of 
an iPhone displaying a procedure. Figure 11(c) is a screen-shot of the location for 
the different parts of the assembly that the technician is working on. 
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(a) (b) (c) 

Figure 11: Prototype Screen-shots of iPhone showing NASA functions 


D. Generation and reuse of software 

The PRACA database that would be used to store and update procedures 
as well as act as an error management system has already been in development 
by NASA. This database and electronic procedures needed for iPhone 
implementation can be reused by NASA for other devices and will not be an 
additional cost to NASA. The introduction of iPhone to ground operations would 
help NASA more effectively use its resources to reduce time and expenses. 


VI. Additional Systems Engineering Activities 

Other systems engineering activities could be performed by NASA to 
ensure that the new proposed system is implement properly. There are two long 
lead items required for the implementation of the proposed new system, 
development of the procedure database and infrastructure. Apple iPhone is a 
commercial off-the-shelf product which will be released in June 2007. 

The risk/value proposition of implementing iPhone is extremely low. 
iPhone would contribute a great deal to the ground operations without 
increasing any risk. It is acknowledged that there are always risks involved with 
using technology. However, these risks are low compared to the risk of missing a 
launch window. 
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The requirements for the device need to go through a validation process. 
This will ensure that the device and system have met all the requirements of the 
technicians. It is recommended that technicians of varying levels and specialties 
be interviewed to determine if this list encompasses all their needs. 

Value Engineering is an organized approach to providing the necessary 
functions at lowest cost. "Value" is defined as the ratio of Function to Cost. 
Therefore, value can be increased by either improving the function or reducing 
the cost. The focus of this system is on reducing risk to have a safe, reliable, cost- 
effective, and timely launch. The primary goal of Value Engineering is not to 
reduce the quality as a consequence of pursuing Value improvements (Value 
Engineering, 2007).Value engineering was not performed for the implementation 
of the new proposed system since it was beyond the scope of this document. For 
further evaluation of the proposed system, it could be performed. Generally, 
during value engineering a more expensive product having a longer expected life 
or having a lower maintenance cost is recommended. 

Other engineering methods and control could be performed by NASA 
before implementing the proposed system. 


VII. Conclusions 


There were two main questions to be answered in this paper: 1) Could 
ground processing activities at the VAB benefit from the use of a mobile hand 
held device by their technicians? and 2)Does there an exist an off-the-shelf device 
that would be able to perform the task efficiently without excessive cost or 
interruption to the current system? 

A review of the literature and historical background of NASA established 
a need for an easy-to-implement technological improvement to displaying 
procedures. Previous unsuccessful attempts led to exploring the practicality of 
using a mobile handheld device. The major products, inputs, resources, 
constraints, planning and effort required for consideration of this type of solution 
have been outlined. After analyzing the physical, environmental, life-cycle, 
functional, and socio-technical requirements, a Functional Analysis was 
performed to describe the top-level, second-level, and third-level functions of the 
system requirements. In addition, the risk/value proposition of conversion to a 
new technology was considered and gave a blueprint for transitioning along 
with the tasks necessary to implement the device into the VAB's current 
infrastructure. A WBS described the elemental work items of the 
implementation. 
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Once the viability of this system was confirmed, a device needed to be 
selected. A Pugh Matrix and House of Quality comparison and evaluation of the 
Apple iPhone, Motorola Q, Blackberry, PC Notebook, and PDA revealed that the 
iPhone is the most suitable device for this task. Subsequent prototyping and 
informal laboratory testing confirmed these results. Hundreds of thousands of 
ground processing person-hours precede every shuttle launch (Semmel et al, 
2006) and new time saving approaches to these critical activities could drastically 
improve efficiency and reduce risks. In conclusion, the advent of the Apple 
iPhone was the technological gateway to streamlining production for the NASA's 
Constellation Program work for the next generation of human spacecraft. 
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C. WBS 
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Mockup Test Environment Development 
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System Revision 
Changeover 
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D. Gantt Chart 
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E. Visual Comparison of iPHONE & Paper Procedures (humblefroc, 2007) 
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F. iPHONE Technical Specs (apple, 2007) 
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G. Risk Assessment Matrix 


Risks 

Consequence 
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probability 
reduction 
due to 
iPhone vs. 
paper (%) 

Missed vehicle 
launch window 

Vehicle rollback 

Fatal launch 

Underutilized 
physical resources 
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■n w 

1 g 

5 3 ^ 

111 
73 C 

c « 

X 

Insufficient 

testing 

Delayed iPhone 
implementation 

Technical Risks 

Technician unable to access PRACA 

L 

L 
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H 

S 

Technician unable to use PRACA satisfactorily 




M 

M 


L 

H 

Technician unable to access procedure(s) 

M 

M 

L 


M 

L 
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S 

Technician unable to access updated procedure(s) 
satisfactorily 

H 

H 

M 

M 

M 

L 

L 

H 

Technician unable to raise problem in PRACA 

L 
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M 

Technician unable to raise a Procedure Change 
Request 
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M 

Technician uses wrong / old procedure 
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Engineer not able to comprehend problem from 
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Technician does not have data to complete 
procedure step 
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L 
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Technician does not have data to fill out work forms 
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Rollback of procedure is not conveyed to everyone 

M 
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Defective component not reported 
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H 
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Defective design not reported 
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related personnel 
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Problem not reported immediately to related 
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Schedule Risks 

Contract negotiation with product vendor (Apple 
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Program Risks 
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Delayed funding for project implementation 
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Consequence Scale: L - Low M - Medium H - High 

Probability Scale: S - Small M - Medium H - High 
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H. Pugh Matrix 


Features 

iPHONE 

Motorola 

Q 

Blackberry 

PC 

Notebook 

PDA 

Physical 

Model 

- 

- 

8800 

Sony VAIO 
VGN-UX280P 

Treo 750 

Weight (oz) 

4.8 

4.1 

4.73 

19.2 

5.4 

Size (in) 

4.5 x 2.4 x 

4.57 x 2.52 x 

4.49 x 2.60 x 

5.91 x 1.5 x 

4.44 x 2.3 x 

[Volume (in 3 )] 

0.46 [4.97] 

0.45 [5.18] 

0.55 [6.42] 

3.74 [33.16] 

0.8 [8.17] 

Memory (MB) 

8,000 

128 

64 

1,024 

60 

Battery Life (hr) 

5 

4 

5 

4.5 

4 

Communication 

Phone 

yes 

yes 

yes 

no 

yes 

Wireless 

yes 

yes 

yes 

yes 

yes 

Internet 

yes 

yes 

yes 

yes 

yes 

Email 

yes 

yes 

yes 

yes 

yes 

Display 

Backlit 

yes 

no 

yes 

no 

yes 

Light Sensing 

yes 

no 

yes 

no 

no 

Screen Size (px) 

320 x 480 

320 x 240 

320 x 240 

1024 x 600 

240 x 240 

Additional 

Provider 

AT&T 

Verizon 

AT&T 

- 

AT&T 

System 

osx 

PC 

Blackberry OS 

PC 

PC 

Camera 

yes 

yes 

no 

no 

yes 

Cost 

$599.00 

$99.99 

$299.99 

$1,603.93 

$399.00 


Features 

Desired Value 

Physical 

Weight (oz) 

small 

Size (in) [Volume (in 3 )] 

small 

Memory (MB) 

large 

Battery Life (hr) 

large 

Communication 

Phone 

yes 

Display 

Backlit 

yes 

Light Sensing 

yes 

Screen Size (pixels) 

large 

Additional 

Camera 

yes 


Ratings: + = better, s = same, - = worse 
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Iteration #1 


Features 

PC 

Motorola 

Blackberry 

iPHONE 

PDA 

Notebook 

Q 




Weight 


+ 

+ 

+ 

+ 

Size [Volume] 


+ 

+ 

+ 

+ 

Memory 


- 

- 

+ 

- 

Battery Life 

S 
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+ 

+ 

- 

Phone 

H 

+ 

+ 

+ 

+ 

Backlit 

D 

s 

+ 

+ 

+ 

Light Sensing 


s 

+ 

+ 

s 

Screen Size 


- 

- 

- 

- 

Camera 


+ 

s 

+ 

+ 

1 + 


4 

6 

8 

5 

Is 


2 

1 

0 

1 

I- 


3 

2 

1 

3 

Total 


i 

4 

7 
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Iteration #2 

PC 

Motorola 


iPHONE 

PDA 

Features 

Blackberry 

Notebook 

Q 




Weight 

- 


+ 


- 

Size [Volume] 

- 


- 

+ 

- 

Memory 

+ 


- 

+ 

- 

Battery Life 

+ 

S 

•— V 

+ 
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- 

Phone 

- 

B 

< 

s 

s 

s 

Backlit 

- 

0 

+ 

+ 

+ 

Light Sensing 

- 


+ 

+ 

- 

Screen Size 

+ 


s 

+ 

- 

Camera 

- 


- 

+ 

+ 

i+ 

3 


4 

7 

2 

Is 

0 


2 

1 

1 

I- 

6 


3 

1 

6 


-3 


i 

6 

-4 
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Iteration #3 


Features 

pc 

Notebook 

Motorola 

Q 

Blackberry 

iPHONE 

PDA 

Weight 

- 

+ 


- 

- 

Size [Volume] 

- 

+ 


+ 

- 

Memory 

+ 

- 


+ 

- 

Battery Life 

- 

- 

5 

* V 

s 

- 

Phone 

- 

S 

H 

< 

s 

S 

Backlit 

- 

- 

0 

s 

S 

Light Sensing 

- 

- 


s 

- 

Screen Size 

+ 

s 


+ 

- 

Camera 

- 

s 


+ 

s 

L + 

2 

2 


4 

0 

Ls 

0 

3 


4 

3 

L- 

7 

4 


1 

6 

Total 

-5 

-2 


3 

-6 


iPhone is the preferred technology. 



I. Functional Analysis and Allocation Documentation 


Activity 

Number 

Activity 

Description 

Required Inputs 

Expected Outputs 

Resource Requirements 

1.0 

Identification of 
Need 

A qualitative and quantitative 
needs statement. 

Revision of current administrative 
initiatives; update of current mission. 
NASA assessment of Orion space 
mission timeline. 

Bush administration's promise to 
return to the moon in the next 
decade. 

2.0 

Presidential and 
NASA Vision 
Announcement 

Identification of need; constituent 
feedback; mission challenges; 
acceleration of space programs in 
other countries. 

NASA centers release new agendas 
supporting new vision. 
Release/Publish official requests for 
proposals. 

Supplier qualification. Report and 
presentation to management. 

3.0 

CEV Contract 
Awarded 

Submission of bids through 
government contracting officer. 
Vendor selection process. 

Begin planning and preparation for 
design phases. Vendor awarded 
based on cost and matching criteria in 
Presidential and NASA Vision 
Announcement. 

Bid reviews and Supplier selection. 
Conceptual design and Functional 
requirements. 

4.0 

Technological 

Advancement 

Mobile computing Based on 
changing societal needs, demands, 
market surveys, and competitive 
product research. 

Innovation and 

Inventions relevant to space flight. 

Benchmarking. Research. 

5.0 

KSC Ground 

Operations 

Initiative 

Based on NASA mission and 
available technology. 

KSC departments push towards 
meeting new goals 

Out-year plans from all divisions. 

5.1 

Ground 

Operations 

funding 

approved 

Request sent to NASA HQ based 
on new initiative 

VAB building prioritizes usability, 
safety, maintainability, and 
reliability. 

Preliminary cost estimate. 

5.2 

Conduct 

Benefit/Cost 

Analysis 

Orion and Ares preliminary 
designs. 

Elimination and selection of feasible 
designs. 

Boundaries of the design. Final cost 
estimate 
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Activity 

Number 

Activity 

Description 

Required Inputs 

Expected Outputs 

Resource Requirements 

5.3 

Analysis of 
conceptual 
system design 
alternatives 

Requires funding and preliminary 
designs. Definition of design and 
success criteria. Evaluation of 
iPhone, Motorola Q, Blackberry, 
PC Notebook, and PDA. 

Shift towards specific design and/or 
production methods. 

Risk analyses; conceptual system 
design evaluation and display; 
creative and meaningful alternatives. 

5.4 

Management 

Alignment 

Organization of personnel and 
resources once funding has been 
approved. Management strategy 
and planning. 

Operations and staffing plan. 
Technician and other support 
personnel alignment. 

Retention, Development, Promotion 
to overcome internal assumptions 
and align management and staff. 
Workshops. 

5.5 

Determine 
Human factors 
Requirements 

Requires management strategy. 

Verification of existing and new 
methods. 

Prototypes and Mock-ups; high 
fidelity testing environment. 

5.6 

Establish 

production 

requirements 

Based on management alignment 
and resource scheduling. 

Scheduling. Final cost estimate. 

Gantt Chart; brainstorming; analogy; 
and checklists. 

5.6.1 

VAB facility 
compliance 

Notification to VAB support 
personnel of production schedule 

Building, System, and Equipment 
layouts. 

Facility Compliance to Inspection 
Environmental and safety programs 
based on NASA standards. 

5.6.2 

Train 

Technicians 

Technicians trained in safety 
compliant facility 

Receive feedback from technicians on 
operation support needs. 

Simulation tools and training 
workshops through cooperation with 
Apple Computer training staff and 
VAB building management. 

5.6.3 

Acquire Test 
and support 
equipment 

Requires facility and supporting 
equipment specifications 

May require system maintenance and 
compatibility updates of current 
system 

New software. Vulnerability and 
serviceability issues addressed. 

5.6.4 

Upload 

Procedures and 

supplemental 

data 

Can be done once the iPhone has 
met the production schedule. 

Documentation of lessons learned. 

Technical Support; existing 
procedures. Reduction of re-work. 
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Activity 

Number 

Activity 

Description 

Required Inputs 

Expected Outputs 

Resource Requirements 

5 . 6.5 

Documentation 
of lessons 
learned 

Ongoing during implementation 
and use 

Knowledge sharing. 

Lessons-Leamed Database serves as a 
clearinghouse in order to apply the 
lessons learned to future project 
phases. 

5.6.6 

System 
operation and 
maintenance 

Ongoing during implementation 
and use. 

Documentation of lessons learned. 

System Operation and Maintenance 
Program works to ensure that 
systems are located and installed 
correctly and kept in top working 
condition. 

5.7 

iPhone 

Acquisition 

Release and delivery of iPhone. 

Testing and verification. Operating 
and implementation procedures. 
Logistics issues. 

Purchase order and maintenance 
contract with Apple. 

5.8 

Test the system 
in user 
environment 

Requires acquisition of iPhone and 
development of system test 
modules. 

Troubleshooting; testing to ensure 
that user tasks are correctly mapped 
within iPhone context and test 
environment. 

iPhone; data Collection and statistical 
analysis. System integration testing. 
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J. House of Quality 
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Techimcal Details 
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CO 

Battery Life 
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CO 
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LO 

Input Device 
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Digital camera 


1 

§- 

I 

o 

HTML Email client 

Resists Scratches and Dent 

Programmable 

| 

? 

1 

u 

M 

3 

O 

c 

0 

ua 

1 
a 

| 

CO 

iPhone 

| 

• 

PU 

MotoQ 

PC Notebook 

Blackberry 

PDA 

Facilitate Climbing 

Physical 

Should be able to fit on one hand / 
other body part with or without 
slight attachements 

3 


9 
















4 

1 

4 

1 

4 

3 

Should be light enough to be earned 
around for 3 hours without 
discomfort 

4 

9 

3 




1 












4 

1 

4 

1 

4 

4 

Should be easily portable with 
minimal cable attachements 

3 



3 



9 


3 

3 









3 

1 

3 

1 

3 

3 

Should be able to remove / attach 
easily 

2 

9 

9 




3 












3 

3 

3 

1 

3 

3 

Should not require extensive training 
before usage 

2 






3 












4 

4 

4 

4 

4 

4 

Input device should not be overtly 
sensitive 

2 
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3 

5 

3 

4 

3 

3 

Functional Performance 

Should not provide any radio signal 
interference with critical frequencies 

4 







3 

3 










4 

5 

3 

5 

3 

3 

Should provide backlight for dimly 
lit work areas 

4 




9 







9 







5 

1 

1 

1 

5 

3 

Can access electronic media 

3 




1 

1 



3 




9 

3 





5 

5 

5 

5 

5 

5 

Can access internet, email 

3 




1 




9 




9 

9 





5 

5 

5 

5 

5 

5 

Can take outgoing and incoming 
calls 

4 







9 


1 









5 

1 

5 

1 

5 

5 

Battery life is atleast 4 hours 

4 
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5 

5 

3 

4 

5 

3 

Can take pictures 

4 




1 

3 
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1 

4 

1 

4 

1 

1 

4 

Features can be enhanced routinely, 
easily programmable 

3 








3 
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3 

1 

4 

5 

3 

4 

User should be able to make notes 

4 




3 

3 

3 
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1 

4 

5 

4 

4 

4 

4 

Life Cycle 

Durable 

4 














9 




3 

3 

3 

3 

3 

3 

Low cost 

1 





3 

3 
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2 

5 

5 
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4 
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Low Maintenance 

2 



3 











9 




4 

1 
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4 

4 

High Reliability (Low mean time to 
failure) 

4 



9 











3 


3 
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3 
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Social 

Should not cause physical damage to 
user 
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3 

3 












1 
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Absolute Importance 


69 

90 

93 

62 

32 

94 

48 

96 

19 

37 

36 

90 

72 

74 

66 

21 

8 

Customer Satisfaction 

Relative Importance 

6.9 

8.9 

9.2 

6.2 

32 

9.3 

4.8 

9.5 

1.9 

3.7 

3.6 

8.9 

7.1 

7.3 

6.6 

2.1 

0.8 
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